[Chapter 22] 22.2 sendmail (smap/smapd) Wrapper
Author: Simson Garfinkel & Gene Spafford
Date: 1999-02-04T00:17:07Z

#

| Chapter 22 Wrappers and Proxies |

## 22.2 sendmail (smap/smapd) Wrapper

The TIS[1] Firewall Toolkit eliminates many of the security problems of `sendmail` by going to the heart of the problem and breaking the connection between sendmail and the outside world. Instead of having a single SUID program (`sendmail`) listen for connections on port 25, implement a complex command set, and deliver mail into users' mailboxes, the TIS package uses a pair of programs - one to accept mail from the network, and one to deliver it.

> [1] Trusted Information Systems is a company that develops and sells a variety of security products and services. The Firewall Toolkit was largely written by a former employee, Marcus Ranum, and made available to the UNIX community for royalty-free use.

### 22.2.1 What smap and smapd Do

The `sendmail` wrapper programs provide the following functions:

smap

  This program accepts messages over the network and writes them into a special disk directory for future delivery. Although the smap program runs as root, it executes in a specially designed `chroot` filesystem, from which it cannot damage the rest of the operating system. The daemon is designed to be invoked from `inetd` and exits when the mail delivery session is completed. The program logs all SMTP envelope information.

smapd

  This program periodically scans the directory where `smap` delivers mail. When it finds completed messages, it delivers them to the appropriate user's mail file using `sendmail` or some other program.

The TIS Firewall Toolkit stores configuration and permission information in a single file - usually /usr/local/etc/netperm-table. Naturally, this file should be writable only by the superuser. For added security, set it to mode 600.

### 22.2.2 Getting smap/smapd

You can obtain the TIS Firewall Toolkit from the computer ftp.tis.com using anonymous FTP.

### 22.2.3 Installing the TIS smap/smapd sendmail Wrapper

Installation of the complete TIS Firewall Toolkit can be quite complex. Fortunately, the `sendmail` wrapper programs can be installed without the rest of the kit. The `sendmail` wrapper can be used to protect any machine that runs `sendmail`, even if that machine is not a firewall.

To install the `sendmail` wrapper, follow these steps:

1. Obtain the TIS Firewall Toolkit from ftp.tis.com.

2. Read the documentation and compile the `sendmail` wrapper.

3. Install the netperm-table configuration file. The default location for the file is /usr/local/etc/netperm-table.

4. Edit the smap and smapd rules to specify the UID under which you want smap to run, where you want the spooled mail kept, where the executable is stored, where your sendmail program is located, and where you want mail to go if it can't be delivered for any reason.[2] In this example, we use uid 5, which corresponds to the user mail in our /etc/passwd file.

   > [2] If you do set the undelivered mail directory, be sure to check it regularly.

   For example:

   >     smap, smapd:    userid 5
   >     smap, smapd:    directory /var/spool/smap
   >     smapd:          executable /usr/local/etc/smapd
   >     smapd:          sendmail /usr/lib/sendmail
   >     smapd:          baddir /var/spool/smap/bad
   >     smap:           timeout 3600

5. Create the smap mail-spool directory (e.g. /usr/spool/smap). Set the ownership of this directory to be the user specified in the configuration file:

   >     # chown 5 /usr/spool/smap
   >     # chmod 700 usr/spool/smap

   Also, create the smap bad mail directory (e.g., /usr/spool/smap/bad). Set the ownership of the directory to be the user specified in the configuration file.

   >     # chown 5 /usr/spool/smap /usr/spool/smap/bad
   >     # chmod 700 /usr/spool/smap /usr/spool/smap/bad

6. Search your system's start-up files for the line in which sendmail is started with the -bd flag, and then remove the flag. This change will prevent `sendmail` from listening to port 25 for incoming SMTP connections, but `sendmail` will continue its job of attempting to deliver all of the messages in the mail queue on a periodic basis. Note that there may not be any such line: your system might be configured to run `sendmail` from the `inetd` as mail arrives.

   For example, if your configuration file has this:

   >     # Remove junk from the outbound mail queue directory and start up
   >     # the sendmail daemon. /usr/spool/mqueue is assumed here even though
   >     # it can be changed in the sendmail configuration file.
   >     #
   >     # Any messages which end up in the queue, rather than being delivered
   >     # or forwarded immediately, will be processed once each hour.

   >     if [ -f /usr/lib/sendmail ]; then
   >             (cd /usr/spool/mqueue; rm -f nf* lf*)
   >             /usr/lib/sendmail -bd -q1h 2>/dev/console && \
   >                     (echo -n ' sendmail')   >/dev/console
   >     fi

   Change it to this:

   >     if [ -f /usr/lib/sendmail ]; then
   >             (cd /usr/spool/mqueue; rm -f nf* lf*)
   >             /usr/lib/sendmail -q1h 2>/dev/console && \
   >                     (echo -n ' sendmail')   >/dev/console
   >     fi

   Alternatively, you can use cron to invoke `sendmail` on a periodic basis with the -q option, by placing the following line in your crontab file:[3]

   > [3] Note that different versions of crontab may have slightly different syntax.

   >     30 * * * * /usr/lib/sendmail -q >/dev/null 2>&1

7. Kill the sendmail `daemon` if it is running.

8. Modify your sendmail.cf file so that the mail user is a trusted user. You need to do this so that sendmail will respect the "From:" address that smapd sets. The trusted user is set with the "T" flag. This example sets root, daemon, `uucp`, and `mail` as trusted users.

   >     ###################
   >     #  Trusted users  #
   >     ###################

   >     # this is equivalent to setting class "t"
   >     # Ft/etc/sendmail.ct
   >     Troot
   >     Tdaemon
   >     Tuucp
   >     Tmail

9. Edit your /etc/inetd.conf file by inserting this line so that smap is started when connections are attempted on port 25:

   >     smtp    stream  tcp     nowait  root    /usr/local/etc/smap     smap

10. Cause `inetd` to reread its initialization file by sending it a HUP signal:

    >     # ps aux | grep inetd
    >     root       129   0.0  1.8 1.52M  296K ?  S     0:00  (inetd)
    >     root      1954   0.0  1.3 1.60M  208K p5 S     0:00 grep inetd
    >     # kill -HUP 129
    >     #

11. Test to see if `smap` is receiving mail by trying to send mail to the root account. You can do this with `telnet`:[4]

    > [4] Of course, replace bigco.com with your own computer's hostname.

    >     # telnet localhost smtp
    >     Trying 127.0.0.1... Connected to localhost.
    >     Escape character is "^]".
    >     220 BIGCO.COM SMTP/smap Ready.
    >     helo bigco.com
    >     250 (bigco.com) pleased to meet you.
    >     mail From:<root@bigco.com>
    >     250 <root@bigco.com>... Sender Ok
    >     rcpt To:<root@bigco.com>
    >     250 <root@bigco.com> OK
    >     data
    >     354 Enter mail, end with "." on a line by itself
    >     This is a test.
    >     .
    >     250 Mail accepted
    >     quit
    >     221 Closing connection
    >     Connection closed by foreign host.
    >     #

12. Check to see if the mail has, in fact, been put into the /var/spool/smap directory (or whichever directory you specified.)

13. Install `smapd` in /usr/local/etc/smapd or another suitable directory.

14. Start `smapd` by hand and see if the mail is delivered.

15. Modify your system's start-up files so that `smapd` is run automatically at system start up.

### 22.2.4 Possible Drawbacks

There are some drawbacks to using the `smap` program as described earlier. The first is that people who are contacting your site on TCP port 25 will no longer be able to execute the VRFY or EXPN SMTP commands that are supported by regular `sendmail`. (Actually, they will be able to execute them, but nothing useful will be returned.) These commands allow a remote client to verify that an address is local to a machine (VRFY) and to expand an alias (EXPN). Arguably, these are possible security risks, but in some environments they are useful (as we illustrate in Chapter 24, Discovering a Break-in).

A more serious shortcoming is that versions of `sendmail` with built-in support for the `ident` protocol will no longer be able to obtain information about the sending user. The use of the `ident` protocol is discussed in the sidebar "Using identd".

If using `ident` makes sense in your environment, you won't be able to use it with `smap` unless you spawn `smap` from another wrapper that implements ident, such as the `tcpwrapper` program, which is described in the next section.

22.1 Why Wrappers? |  | 22.3 tcpwrapper